OSI high level design document

The Root_KOS and SLIP Enterprise

December 9, 2001

Software available from OntologyStream Inc

Obtaining Informational Transparency with Selective Attention

Dr. Paul S. Prueitt

President, OntologyStream Inc

OSI high level design document

The Root_KOS and SLIP Enterprise

December 9, 2001

Version 0.0.0 of Root_KOS is released for comment. Root_KOS is to be the foundation for future SLIP Browsers and for technology developed due to SLIP design elements (see 2005 work).

Overview

Root_KOS loads and saves tabular files to/from memory, and responds to scripted commands.

Loading and saving tabular files is important because SLIP Browsers work with data that is in a system file or in a special In-Memory Referential Information Base (RIB) data structure ( e.g. the RIB is a key-less hash table).

The SLIP Warehouse and SLIPCore Browsers transform data that resides on text files. (See Figure 1). Both depend on a Root_KOS kernel.

Figure 1: KOS Browsers work together

The Warehouse Browser takes any tab delineated audit log and produces a data mart and a combinatoric expression of link analysis within the values of an event log. Both of these files are produced using In-Memory Referential Information Base techniques. Once the files are produced then the SLIPCore Browser can use them.

The SLIPCore Browser uses In-Memory RIB techniques to develop event detection.

The Event Browser is launched from the SLIPCore Browser and some data resources are exchanged. SLIP atoms are identified in the SLIPCore Browser and those atoms involved in a event are conveyed to the Event Browser.

Figure 2: Some early event chemistry drawings

The RIB uses system files, memory maps and mathematical objects such as lines and arrays. OSI’s RIB technology is derivative of mathematical formalism called structural holonomy. Structural holonomy is the innovation of Paul Prueitt and is based on his interpretation of the work of renowned neuroscientist Karl Pribram. This formalism is of the nature of mathematics and yet has grounding in experimental literatures from biology and neuroscience. The basic work has been privately peer reviewed from over a decade, and is the subject of two separate PhD dissertations (one in Germany and one in Australia).

Structural holonomy is being made public domain in order to facilitate the development of RIB systems in support of knowledge technologies that depend on very fast data aggregation methods.

Basic Functionality

OSI’s RIB technology is a full data base management system that is designed to minimally cover the requirements of many classes of data aggregation, artificial neural network, evolutionary programming and data warehousing systems. The smallest version of the RIB technology is part of the 172K SLIP Warehouse and the 348K SLIP SLIPCore Browser. Both of these systems are operational.

The Root_KOS is a development environment, complete with a minimal RIB system. Root_KOS is applicable to elementary research in Natural Language Processing, full text mining and warehouses, and certain types of eBusiness functions. The development of deployable applications are streamlined.

Figure 3: The Root_KOS User Interface and data structures

The exit and help functions are the most basic of all scripted commands. Any KOS Browser can recognize scripted commands by

1) Command line input,

2) Certain mouse events on nodes of arcs in the graph window, or

3) Mouse events on the node tabs at the top of the graph window

Scripting provides for user gestures as response to the presentation of state information from an internal ontology or finite state machine. Algorithmic responses to a human gesture produce changes in

1) The ontology or finite state machine,

2) Changes in auxiliary resources such as system files and

3) A textual response in the response line and/or a sound response.

Any KOS Browser will have:

A.1: Modal transforms that switch the view in display areas and change the system’s response to script commands

A.2: Graphs that are generated from a process model. The elements of the graph are active objects.

A.3: Allow the selection and movement of objects within the graph.

A.4: Selection and movement will change the state of corresponding ontologies or finite state machines.

A.5: Selected objects will refer to contents. So for example, selecting a node and typing “Open Event Browser” (or “oeb”) will take the contents of the node and move this content to a new instance of the Event Browser. Selecting a node and typing cluster” (or “c”) will cluster the atoms corresponding to that node.

A.6: Grammatical interface composed of a command/response line with history.

Any KOS Browser will have a formal Program Interface (PI) that is completely implemented through a categorized message stream interface. The machinery for the PI is complete in the Root_KOS and extendable in any KOS Browser.

Project plumbing in the root KOS provides maximal notational affordance by using extensible graph based formalism.

States and gestures as KOS foundational notion

The notation for states, gestures and locations is:

The set of world states S = { s_j }.

The set of gestures G = { g_i }.

The set of locations L = { L_k }.

A formal theory of states and gestures provide a computational means to discuss middle level event paths in human computer interactions, particularly for telelearning and virtual knowledge collaboration. These states can be used as part of the mechanics of what we call a "knowledge processor".

The notion of location allows for the development of enterprise KOS. Notational engineering is being researched and extended based on some early work of Jeff Long. Mr. Long was Director of the Notational Engineering Lab at George Washington University (1996 – 1998) and is now developing ontology for the Department of Energy.

The formal theory of states and gestures is built from a precise formalization of computer game and user interactions in Multiple User Domains (MUDs) (such as the Palace 2-D chat environment) and Role-Playing Games (RPG) (such as ChronoTrigger or Zelda.) To a certain extent, the theory is modeled after, but generalized from an ancient semiotic system called the I-Ching. The I-Ching has 64 world states and requires human interpretations of those states. Like the ancient I-Ching, and semiotic system (of signs) involves a formal part and a non-formal part.

Gestures and states can be modeled as the fundamental units of a specific finite state machine. Thus, under any such designation, the related model of event sequences is computable. The KOS, however, must represent the invariance in the data AND the mental states of humans. This means that our effort to representation the contents of mental events within the context of discourse, should be split into two parts. These two parts are

1) The aggregation of data invariance and

2) The representation of user response history in terms of the set of aggregated invariance.

The aggregation of invariance is used to represent the computer processes, and the user response history is used to represent the natural world. The communication between finite state machines is used to control and allow user (community) focus on a specific set of issues. This control of focus provides universal “Informational Transparency with Selective Attention”.

We can assume that a set of states, S = { s_j }, are created before hand and the gestures G = { g_i } are a set of stored responses. This would mean that S and G are actually the atoms of finite state machine. However, the existence of event states may be actually implicit unless actually instantiated as part of an event. In this case, it is proper to refer to S and G as virtual finite state machines.

In the course of working with the KOS Browsers, users select gestures in response to a presented state from the computer. This pairing of state and gesture is a represented as a mutual decision event.

In the Event Chemistry being developed by OSI, the finite state machine is a virtual combinatoric expression of the aggregation of abstractions called “SLIP atoms”. This abstraction plays a role similar to the abstractions we have in physical chemistry. Each atom has a specific set of linkage potential. The manipulation of the linkage potential (called “valence: in physical chemistry) leads to the formation of chemical compounds.

The notions of an “atom” and “chemical valence” are useful abstractions. In the Event Browser we use a different set of abstractions to visualize the parts of events and the means that these parts have to be a compound in a larger event.

Figure 4: event chemistry

An abstraction from the signatures of real occurrences leads to event chemistry (See Figure 4).

The Internal processes of Root_KOS

KOS and RIB represent a new paradigm for software development. Maximal responsiveness to a software engineer occurs through the modification of a KOS file called clsFunctionality. It is as if the engineer develops the behavior of the KOS Browser by equipping the Browser with a language.

As the language is being created, the Program Interface (PI) must be equipped with a message stream and program code. The programmatic object of the functionality class is extended and in this way affords access to process and data models required by the program code. The creation of the language requires special training. A certified knowledge engineer of a process theorist has the training necessary to specify process models. Our problem has been in putting the details of a process model into a computer program’s methods. So the knowledge engineer generally needs a first rate software engineer to evolve the Root_KOS into compliance with a process model.

If an individual has both a background in software development and a background in knowledge engineering or process modeling, then we call this individual a notational engineer.

Rapid development of new functionality has been demonstrated during the recent development and deployment of two KOS Browsers for an experimental Incident Management and Intrusion Detection System (IMIDS). How was this done?

The frmRootKOS form module contains code that runs when change-message-events occur, as produced by small control ontology. This architecture provides zero entanglement between the PI and any process models.

Functionality needed by the process model is accessed through a method called Interpret. Grammatical control further decouples the user entanglement from PI controls, and yields a solution complexity as a function of grammatical entanglement, a much simpler learning curve for humans.

The interpreter is a simple word-pattern match against command line words. However, the interpreter function proper within the project is a method of the Functionality class, so the notational engineer is afforded structured scripting within the interpreter method against an apparent object model defined by inter-linking interfaces abstracted within clsFunctionality (clsFunctionality is a multi-interface class). A grammatical command may therefore be notationally interpreted into any degree of functional-complexity by direct qualification into the live process and data models when interpreting.

There is, as yet, no notational support in the root KOS for hierarchical data objects. It is presently including the necessary process-model components to support tabular data, as in Tab/CR delimited row/wise text data sets. This approach is biased toward requirements of the Event Chemistry Browser as the first vertical solution. The hierarchical version, whether blended with the root KOS templates as subsequent releases, or as a second generation root KOS, will provide all root functionality needed for Topic-Graph solutions.

A third IMIDS Browser was completed in January 1^st, 2002, and together this suite of software products was made available for deployment. The SLIP Browsers are available for private use on a home personal computer. (send email)

Any software solution using the root KOS foundation will entail

1) Adding additional methods to functionality class that create/modify the data-model

2) Adding interface implementations within the functionality class that serve to define hold state of an hierarchical programmatical object

3) Adding message-consumer functions in the PI form that manipulate graphical constructs that emerge from the message stream

The stand alone use of SLIP IMIDS was available January 1^st, 2002. The systems behavior is deployable as small applications that will run without installation on any Window’s environment.

OSI envisions the structured deployment of SLIP IMIDS throughout the US government’s Computer Emergence Response Teams (CERTs) worldwide.

KOS Enterprise Architecture

The OSI Enterprise Architecture will produce a Knowledge Extraction and Management Process as the back end processes and full functionality stand-alone KOS Browsers as clients. The client and implement this architecture into either .NET. or Java OS.

The major innovation of the KOS Enterprise Architecture is the tri-level architecture developed by Prueitt (1996 – 1998) while working on declassification technology. The tri-level architecture binds together the functions of stand alone SLIP IMIDS. The notion of locations becomes critical.

Remember that the notation for states, gestures and locations is:

The set of world states S = { s_j }.

The set of gestures G = { g_i }.

The set of locations L = { L_k }.

OSI’s formal theory of states and gestures provide a computational means to discuss middle level event paths in human computer interactions. These states can be used as part of the mechanics of what we call a "knowledge processor". The purpose of the knowledge process is to provide “informational transparency on Internet events and selective attention to those events that are directed at our infrastructure vulnerabilities.

While tested in limited fashion, the tri-level has never been implemented in a commercial system. The tri-level architecture is designed to be implemented within a data mining, data warehouse, data store paradigm. The architecture provides a very high Precision/Recall push-pull information ecosystem. However, it must be noted that the tri-level, like the SLIP has a low technology footprint and uses completely independent software modules.

The functional components

The functional components of the tri-level process are:

1) Data sources and data transformation

2) Mining and cleaning procedures

3) Index Factory and Index Control module

4) Data source to Index Factory transmission resource

5) Index Archive and Artifact Archive

6) Full-text and data Warehouses

7) Warehouse Control module

8) Archive to warehouse transmission

9) User interfaces (Dialog Store)

10) Knowledge Management module between warehouse and users.

11) Warehouse to Dialog Store transmission

The SLIP Browser for Intrusion Detection and Incident Management Systems (IDIMS) was developed with the tri-level architecture in mind. Once the data invariance is identified in the SLIP SLIPCore Browser, then the Event Browser is used to develop an exact understanding of events. These events and event substructure is then indexed globally as part of a rapid response process to cyber warfare or hacker activity.

Mining and cleaning procedures are managed using templates representing pre-packaged solutions derived from case studies and original data sources. The mining operations will feed directly into the Index Factory.

Indexing is categorical in nature and is in the form of category and placement policies. A description of policies and the role they play in the voting procedure is written in Chapter 14 of Prueitt’s book and in Appendix A of this book. The Index Factory will obtain descriptive metadata from the data source or via a mining operation. Perhaps a frame filling technology, or Petri nets, will be used here. This metadata places the units into historical or nominal reference.

Adaptive profiles and the mediation of state/gesturing pairing

The adaptive formation of category policies follows these steps:

1) Stochastic clustering (or other knowledge artifact generation procedures) is used to identify atoms and event structures.

2) A Universal Set, of all possible event categories, enumerates the collection of known events. This is done using the placement policy over and again and then using ranking based on placement preferences. The method of descriptive enumeration is used as a stopping criterion.

3) Performance is measured using polling instruments and other types of user feedback. These performance metrics suggest when a new category policy should be projected.

4) Category policies are archived to allow record keeping, and trending as well as theme analysis.

Measurement of performance can be carried out using the state gesture pairing that is essential also to the interface design.

State-gesture pairing can be from the point of view of the computer Output waiting for the user Input (OI) or from the point of view of the user (IO). In OI the state of the computer requires that the user initiate a response (gesture) that is structurally computable. The SLIP IMIDS provides this anchor.

In IO the human presents a state to the computer and the computer computes a response (gesture). The selection of a gesture by a human is itself a complex event that can be simulated by the pairing mechanism.

The tri-level concept has three levels, the ultra-structure and substructure and the middle world. The middle world is relative to the ultra-structure and substructure. The substructure is the set of logical atoms. In the SLIP technology these logical atoms are the abstractions that we have called SLIP atoms.

Human gestures and computer state are linked by a symbol system, as part of an expression of computational memory and human anticipation. Both of these two processes are used to create event chemistry. The two processes can be thought of as aggregation and projection. In fact most machine intelligent systems employs one of these processes but not both. This is like having an up but not a down or a down but not an up. One needs both an up and a down to provide for an analog to human synthesis and interpretation.

The projection from a universal representation of all possible events, about a specific Universe of Discourse, can be considered as a constraint on an assembly of logical atoms during the generation of the event chemistry. Metaphorically, the projection plays the role of a constraining ecosystem during the life of events controlled by this ecosystem. The logical atoms play the role of tacit causes of the event. The two processes are only active while the event is establishing itself as a transient reality, such as a mental event. Both are producing the exact same state. A measurement between the two outputs of these complementary processes can be treated as an utility function and thus jointly create a single pair ( s_j, g_j ) using various methods such as min-max optimization or evolutionary computing.

The tri-level architecture allows one to control a pair of processes that create either states or gestures. The created states are to be regarded as the consequences of a query or other "retrieval" mechanism. The pairing is thus completed under the control of human judgment, or can be simulated using a random number generator or graph theoretic construct such as Petri nets.

A similar pair of processes will simulate the production of gestures and is useful in scalability studies and performance testing. These processes are to be coupled with a decision engine. However, the human gesture response is required to be a selection of one option from a set of options that are allowed the user by the voting procedure.